1. Field of the Invention
This invention relates generally to electronic commerce and, more specifically, to an Improved Method and System for Electronic Data Sales and Distribution over Wide Area Computer Networks
2. Description of Related Art
Software sales over wide area networks and in particular, the World Wide Network have expanded rapidly to the extent that today a large portion of all software sales are conducted over the World Wide Web. There are however, several problems due to the conventional arrangement of these e-commerce systems. If we first turn to FIG. 1, we can begin to understand how conventional sale of software over the World Wide Web is accomplished.
FIG. 1 depicts conventional wide area network based e-commerce layout. As we can see, Wide Area Network Conduits 10 (typically known as the World Wide Web) has an infinite number of participants. Some examples as it might apply to the present invention will include a Wide Area Network Serve (for example 12A, 12B, and 12C) where e-commerce service supplier presents the environment for which a customer can purchase the suppliers software. Within each server 12, resides the Software Distribution Points 14A, 14B, and 14C within which the actual master copies of the suppliers software resides. Each supplier has the ability to modify or otherwise access the Distribution Points 14 via the Supplier Terminal 16. Typically new or revised copies of the software are to distributed or housed on the supplier site in their Local Area Network Server 18. Customers then, have the ability to “visit” a particular e-commerce site via their own Personal Terminal 20. If we now turn to FIG. 2, we can examine how the supplier might post their software product at each Server 12 for distribution to customers.
FIG. 2 describes the conventional supplier posting process for a software supplier to establish and maintain wide area network based software sale. At the conclusions of these Supplier Development Process 200, includes both new software development as wells as releases of revised, improved, or corrected software. And for each Software Release 202, a series of steps must occur. First, the software or revision is developed for sale 204, then for each e-commerce service provider 206, the software must be personalized so that it complies with the format and licensing requirements of each e-commerce site 208. After which, the e-commerce site compliant software is uploaded to a particular e-commerce site 210. In which steps 208 and 210 must be re-executed off each e-commerce supplier. Once all e-commerce suppliers have had an upload 212, then the new release process has been completed 214 and the customers are able to purchase the particular software revision 216. The problem with this conventional posting process is that for each software release, not only does new software have to be completed and tested, but also for each difference between each supplier mandates that the software supplier must again revise and upload the software potentially several more times prior to the customer being able to purchase it from all the e-commerce service providers. The multitude of revisions and uploads can create a huge amount of work for the software supplier, particularly when new additions or corrections are created. What is needed is a software supplier posting process that minimizes the number of revisions and uploads that the supplier must conduct in order to have widespread e-commerce outlets for customers to purchase their software. If we now turn to FIG. 3, we can examine conventional customer e-commerce software purchase process 216.
FIG. 3 is a conventional customer e-commerce software purchase process. It can be understood that each e-commerce supplier may decide to employ a different configuration. For example, the e-commerce supplier 12A may first require the customer to download their software from their server 300. After which, the customer must run what is conventionally know as a setup.exe program 302 in which the software will function 304 and only for a limited time. This is known as a try before you buy software purchase. At anytime before or after the end of the try before you buy period, the customer may chose to purchase the software 306 after which they are provided with a key code by the e-commerce supplier. For example, 12A that is entered into the software 308 after which the software functions without limitation. In another e-commerce site 12B, for example, a different method for purchase may exist. When the customer purchases the software 310, they then download the software from the supplier 12B, 312 and then run the setup.exe file 314. The difference here, is that prior to the customer downloading the software 312, the purchase must be conducted. As can be appreciated, the process provided by supplier 12A will create a totally different environment and a different software package then that software provided by the process of supplier 12B. Furthermore, supplier 12C might engage in yet another version of the purchase process. The problem with these prior processes, is that the interface to the customer is inconsistent and depending upon which e-commerce site they visit, they will experience a different purchase process. What is needed, is a way for the supplier of software to determine what the customers purchase process will be while still maintaining the necessary security requirements. To review, if we now turn to FIG. 4, we can see that the customer from their terminal 20 buys software by making a payment 400 to the e-commerce server 12 after which the software is downloaded 402 from the e-commerce server 12 to the customer terminal 20.
FIG. 4 depicts the conventional relationships between the customer, the e-commerce, the service provider, and the software supplier. Any updates or new releases to the software 404 originate from the supplier terminal 16 and are uploaded to the e-commerce server 12. Furthermore, when sales are made, the records and payments are transmitted form the e-commerce supplier 12 to the supplier terminal 16. If we now turn to FIG. 5, we can see that surprisingly the conventional software application 500 is represented by this depiction of a storage media as a single discrete package 500.